feat: setup steps, optional test name, changelog (v0.4.0)#38
Conversation
- Setup steps (`setup = true`) always run even when checkpoint-skipped and are excluded from pass/fail tallies - Test file `name` defaults to the file stem when omitted - Add CHANGELOG.md based on Keep a Changelog - Release workflow extracts notes from CHANGELOG.md
![cadence[bot]](https://avatars.githubusercontent.com/in/2857168?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cadence PR Review
Goal
Add three user-facing changes for v0.4.0: setup-step semantics in execution/reporting, default test names when name is omitted in *.test.toml, and changelog-driven release notes. The relevant session evidence shows the user explicitly asked for filename-based default names, and the PR description scopes the rest of the release work and validation.
| Signal | Details |
|---|---|
| Score |  strong requirement coverage, lighter workflow verification |
| Models | claude-opus-4-6 |
| Phases | 65% implementation, 25% verification, 10% release prep |
Key Decisions
- The user chose to ship the parser fix together with setup-step behavior, release-note workflow changes, and the v0.4.0 version bump in one PR.
- The model implemented optional test names by introducing a separate raw deserialization struct and deriving the default from the source filename during parse.
- The user and model verified the broader behavior changes with local
cargo testandcargo build --release, while leaving the tag-triggered release workflow unverified in the PR test plan.
Outcome
The model largely achieved the stated PR goal and stayed aligned with the requested behavior changes, especially on default test naming and the setup-step execution/reporting semantics. The main gap is verification discipline: the release workflow change is plausible but not exercised here, so a meaningful part of the release-focused scope still relies on manual follow-through.
Recommendations
-
This PR shows the model can implement workflow edits cleanly, but automation changes are harder to trust from diff inspection alone. Adding an explicit local simulation requirement would improve confidence on similar release-focused PRs.
Before
Make the release workflow use CHANGELOG.md. Reframe
When a PR includes GitHub Actions or release automation, include a prompt requirement to simulate the changed script locally and summarize the exact expected artifact or release-note output.
If this review was useful, please react with 👍 below. Otherwise, react with 👎.
1 participant
Summary
setup = true): always run even when checkpoint-skipped, excluded from pass/fail tallies, tolerate missing RESULT markersnamefield in*.test.tomlnow defaults to the file stem when omittedTest plan
cargo test— all 189 tests passcargo build --release— compiles cleanly